Authentication systems are used for security purposes to verify the authenticity of one or more parties or entities during a transaction. Traditionally, authentication systems have been manual, involving personal recognition or quick verification of a party via some form of additional identification. One very familiar authentication process occurs when purchasing an item with a personal check. The sales clerk will process the check only if he/she recognizes the person writing the check or if the person presents another piece of identification (e.g., a credit card or driver's license) to verify their authenticity as the specific person who is tendering the check.
Today, many authentication systems are electronic. A familiar electronic authentication system is a common credit card purchase. A card issuer issues a credit card to a consumer to enable the consumer to purchase items on credit. Credit cards that are primarily in use today consist of magnetic-stripe memory cards that have a single magnetic stripe (“mag-stripe”) on one side. The magnetic stripe contains information about the card issuer, the consumer, and his/her account.
During a purchase transaction, the consumer presents the credit card to a sales clerk, who authenticates the card before finalizing the transaction. The credit card authentication process is typically performed “online”. The sales clerk swipes the card through a reader, which extracts the card data from the magnetic stripe and transmits the data over a network to the card issuer (or a third party contracted to handle authentication requests). The card issuer checks to ensure that the card is still valid (i.e., has not expired), has not been revoked as being lost or stolen, and the corresponding account is below the authorized credit limit. If the authentication is successful, the card issuer returns an approval and the sales clerk completes the transaction. With conventional telecommunications and computerized processes, the entire credit card authentication process is typically handled in an acceptable length of time, such as a few seconds.
Today, there is increasing use of “smart cards” in place of, or in addition to, conventional magnetic stripe cards. A “smart card” is a thin card about the size of a credit card, with a built-in processor that enables the card to modify, or even create, data in response to external stimuli. The processor is a single-wafer integrated circuit (IC) which is mounted on an otherwise plastic card. For this reason, smart cards are often referred to as one class of “integrated circuit cards” or “IC cards”.
As smart card technology becomes more pervasive, it paves the way for conducting a variety of new transactions, such as electronic money, which are not available with conventional mag-stripe cards. Smart cards also open up the arena for conducting certain new “offline” transactions, which do not involve validating a card with a central authority. These offline electronic transactions are typically performed without the human intervention, such as from a sales clerk.
Smart cards are equipped with authentication capabilities used to establish the identity of an entity with which it is communicating. An identity can be an individual human being, a business, a piece of computing hardware, software code, a network node, an organizational role, or an accreditation agent. Smart cards also have authorization capabilities to control access to resources stored on the cards or elsewhere.
Typically, smart cards recognize a small, fixed number of generic authenticatable identities, typically only two or three. While a card may provide different ways to authenticate these generic identities, the access privileges granted to an authenticated identity do not depend directly on which method was used to perform the authentication. Smart cards have resorted to this collapsing of identities on the grounds of saving space and in the era of single-use, purpose-built cards this optimization caused little trouble.
Reusing or “aliasing” a fixed number of generic identities across different datasets has a number of shortcomings in the era of multi-use and multi-application cards. First, all data needed by a particular identity must be organized in a way that does not trigger changes in authentications or authorizations as it is used. This, in turn, means that data access privileges become implicitly intertwined with data location and layout; changing the location of a file may change who can access the file and, if it is a key file, who can access other files. Secondly, data access policies that involve more than the number of generic identities supported by the card simply cannot be expressed.
Accordingly, it is desirable to design a smart card that can track an arbitrary number of identities and that makes data access policies independent of data file location.
Identities authenticated to today's smart cards only persist for the duration of the session in which they are established. As a result, all identities that authorize a transaction or access to data on the card must authenticate themselves to the card each time it is used. This need to concurrently locate in time all the parties that must either approve or witness a card interaction severely limits the scope of applicability of the data and computational security provided by smart cards.
Accordingly, there is a need for improving smart cards to allow multiple uses of a card without requiring repeated authentication of an identity.
Additionally, in some instances it can be desirable to either restrict or extend the identities that are authenticated for a particular transaction. There can be several reasons for doing this. For example, it may be desirable to add one or more identities to the authenticated identities to enable operations that otherwise could not take place without them. Alternately, it may be desirable to limit the authenticated identities in a particular transaction because it is not necessary or desirable to have all of them authenticated. Yet, current smart cards do not provide for situationally-dependent, extension and restriction of authenticated identities on a transaction-by-transaction, or file-by-file basis.
Accordingly, there is a need for flexible, situationally-dependent extension and restriction of authenticated identities.
Apart from issues facing smart cards, another area of concern for facilitating a secure environment is the use of protected resources. One solution is to use capabilities to grant or deny access to the resources. A “capability” is like a ticket that lets you do a particular thing. A key is a familiar example of a capability. Its possession is necessary and sufficient to gain access to what it protects. Neither the key nor the lock knows who is using it and the lock doesn't maintain a list of all keys that can open it.
In a computer system, a capability ticket might permit someone to read a particular file. A ticket is presented to the file system, which validates the ticket and lets the ticket presenter read the file. Operating systems have been constructed using capabilities rather than access control lists to control access to their resources. Despite their usefulness in attacking the problems of access control lists, capabilities have not become popular for a number of reasons, including the difficulty of securely creating capability tickets.
Accordingly, there is a need for a system to securely create capabilities.